SAP TM模块

您所在的位置：网站首页 › SAP EWM模块价格 › SAP TM模块

SAP TM模块

2024-07-10 01:54| 来源: 网络整理| 查看: 265

TM模块开发知识梳理

1 概述

1.1 缩写字典

1.2 业务流程概览

1.2.1 订单管理

1.2.2 运输计划

1.2.3 运输执行

1.2.4 费用与结算

1.2.5 主数据

1.3 开发框架概览

2 TM开发框架

2.1 MVC架构

2.2 BOPF

2.2.1 BOPF组成部分

2.2.2 常用事务代码及使用方法

2.2.3 Service Manager

2.2.4 Transaction Manager

2.3 FPM

2.3.1 框架介绍

2.3.2 技术框架

2.3.3 相关接口

2.4 Wire Model

2.5 FBI

2.5.1 FBI View(design time)

2.5.2 FBI View Instance(runtime)

2.5.3 FBI Controller(runtime)

2.5.4 Conversion Classes

2.5.5 Exit Classes

3 TM报表POWL

4 TM表单打印

5 TM增强开发

5.1 BOPF增强

5.1.1 创建增强对象

5.1.2 创建字段扩展

5.1.3 创建子节点

5.1.4 创建活动

5.2 FPM增强

5.2.1 字段增强

5.2.2 操作增强

5.2.3 页签增强（数据来源于增强的子节点）

5.2.4 页签增强（数据来源于外部非业务对象节点）

5.2.5 页签增强（普通FPM增强）

5.2.6 main toolbar按钮增强

6 TM开发常用技巧

1 概述 1.1 缩写字典

缩写

全称

Transportation Management

OTR

Order-based Transportation Requirement

DTR

Delivery-based Transportation Requirement

FWO

Forwarding Order

FWQ

Forwarding Quotation

FUBR

Freight Unit Building Rule

Freight Unit

Freight Order

ADS

Adobe Document Service

BOPF

Business Object Processing Framework

FPM

Floor Plan Manager

FBI

FPM BOPF Integration

OVP

Overview Page Floorplan

OIF

Object Instance Floorplan

GAF

Guided Activity Floorplan

1.2 业务流程概览

TM（Transportation Management）主要包括四个主要步骤：订单管理，运输计划，运输执行，费用与结算，

具有以下几点优势：

l 减少成本，提升操作效率

l 提高运输工具的容错率及资源利用率

l 高效的端到端订单及进程管理

l 高效的物流及执行过程

l 提高执行的可视化及响应率

图表 1

1.2.1 订单管理

l 与ERP集成：通过PI，由销售订单或采购订单生成OTR（Order-based Transportation Requirement），或由交货单生成DTR（Delivery-based Transportation Requirement）

l 与第三方集成：第三方平台通过PI创建FWO（Forwarding Order）或在TM系统中创建FWQ（Forwarding Quotation），然后发送到第三方确认后，基于FWQ创建FWO（类似于采购订单之前的询价单）

l 独立系统：直接在NWBC界面创建FWO

1.2.2 运输计划

l 运输主控室（负载可视化）

l 计划与优化

l 运输工具选择

l 订单招标

运输计划的作用：根据订单管理中的凭证及FUBR（Freight Unit Building Rule）产生的FU（Freight Unit），对FU进行容量和运输网络的计划，并产生FO（陆运则是Freight Order，海运和空运则是Freight Booking）

1.2.3 运输执行

主要包括以下几点：

l 事件管理：常用的事件包括装货开始，装货结束，启运，运达，卸货开始，卸货结束等

l 凭证打印：基于PPF（PPF的讲解在后续，这里可以理解为一个触发器）实现通过Smart Forms开发或Adobe Forms与ADS（Adobe Document Service）开发的表单，在某个条件后才可查看，并能在NWBC界面预览

l 与EWM的集成：如货物出库后，司机才能点击提货，并随后触发启运事件等功能

目前与APP进行集成的，基本都是运输执行部分，能让司机通过手机实现对FO事件的管理以及行车记录单等凭证的打印来查看运输任务

1.2.4 费用与结算

l 定义运费（标度，费率表，计算单）

l 定义货运协议或转运协议

l 生成结算凭证

l 将代运结算凭证集成到SAP ERP中，生成财务凭证，用于开票给客户（收款凭据）

l 将结算凭证集成到SAP ERP中，生成采购订单，进而生成相应的财务凭证（付款凭据）

l 可分为货运结算，内部结算和代运结算：其场景用通俗的话来讲就是，当别人帮我们运时候就是货运结算，自己运自己的时候就是内部结算，我们帮别人运的时候就是代运结算

1.2.5 主数据

l 位置

l 产品（即ERP中的物料主数据）

l 业务伙伴（用于承运商等）

不同的业务场景需要的业务主数据不同：

l 国内/国际外向运输：由SAP ERP发起，销售订单和交货单集成是主要的步骤，因此，客户，工厂，装运点，产品等主数据需要同步到TM系统

l 国内/国际内向运输：由采购订单集成触发，因此，供应商，工厂，装运点，产品等主数据需要同步到TM系统

l 外包运输：通过TM系统来执行基于订单的承运商选择，招标，因此，运输在其他运输公司完成，因此不用关心细节，那么ERP就成了主数据的主导系统，包括位置，业务伙伴，产品，运输工具等主数据

1.3 开发框架概览

http://note.youdao.com/noteshare?id=08e30c63bbbf05c662a4978fb822352e&sub=DA09EBD7F1224C15AFF3E6E4188378E3

2 TM开发框架 2.1 MVC架构

TM整体开发架构基于MVC架构，即Model,View,Controller，其中Model对应的就是TM模块的核心BOPF（Business Object Processing Framework），View对应的就是NWBC界面，通过FPM（Floor Plan Manager）实现，而Controller对应的是FBI（FPM BOPF Integration）。

TM模块开发都是基于面向对象实现的，因此封装性和可读性非常强。

数据通过BOPF以业务对象的形式存储下来，使其具有层级和关联关系，更易与业务场景进行理解，接下来会对BOPF进行详解讲解，然后通过FBI将数据进行逻辑处理后，通过FPM展示出来。

2.2 BOPF 2.2.1 BOPF组成部分

BOPF包含以下组成部分：

l 节点（Nodes）：节点是业务对象的一系列语义关联属性的集合，并通过父节点和子节点的形式，使其产生层次和关联。通俗来讲，以交货订单为例，分为了交货订单抬头和交货订单行项目，那么如果以BOPF的节点形式存储，即可将抬头作为父节点，抬头的属性即抬头表的LIKP的各个字段，也就是说属性就是数据结构中的字段；行项目作为子节点，这里只是一个简化模型，仅供理解。

因为对应的属性实际上就是结构中的字段，因此可以对节点进行增强，增加属性

l 关联（Associations）：指两个节点之间的关联，关联方式可以为方向性关联（从A到B与从B到A结果可能不同）或非方向性关联，并可输入参数来筛选关联结果

l 操作（Actions）：个人认为这是TM模块非常好用的一个功能，可以理解为TM中的各种BAPI，只不过由于基于面向对象，都封装在类的方法里：在其他模块，需要通过BAPI*去查询或者通过调试标准程序或者查看相应包下的函数来查找我们需要的标准BAPI，而TM模块将操作分配在各个相应的节点下，使得我们可以通过业务场景能直接在对应的节点下找到我们需要的操作。

l 确定（Determinations）：即由输入参数进行逻辑处理后，确定和填充业务对象节点的属性值

l 验证（Validations）：可用于操作之前判断是否符合相应的触发条件

l 查询（Queries）：类似于select语句，但是灵活性不高

TM模块中的开发基本都是围绕BOPF进行，因此这部分是整个模块的核心，必须要掌握的基础

2.2.2 常用事务代码及使用方法

l BOBF：用于浏览业务对象及业务对象详情，如下图：

图表 2

展开Transportable Business Objects->Business Process Objects->/SCMTMS/TOR（货运订单业务对象名），然后双击查看详情

通过Node Structure可以查看业务对象的节点层级结构，右方可查看节点的相关信息，包括节点名，数据结构名，及扩展数据结构名（用于节点增强），以及节点对应的数据库表

图表 3

通过Node Elements可查看节点对应的其他属性，这里不一一展开。

图表 4

l BOB

用于BOPF增强，会在增强的章节中介绍

l BOBT

用于查询数据，由于在TM系统中，不是以凭证号作为key值（凭证号为Alternative Key），因此需要打开多个界面复制粘贴进行查询，非常不方便，通过此事务代码，只需要输入一个key值和业务对象名（Key或Alternative Key均可）即可搜索此单据所有的信息（由于BOBT不是必需知识点，后续会专门介绍BOBT的使用方法）

界面图如下：

图表 5

2.2.3 Service Manager

前面介绍了业务对象，那么如何访问它呢？我们需要获取对应业务对象的service manager实体，进而对此业务对象进行增删改查等操作。

查询数据主要为示例程序的三种方式：

l Retrieve

l Retrieve by association

l Query

DATA: lt_root TYPE /scmtms/t_tor_root_k, lt_root1 TYPE /scmtms/t_tor_root_k, lt_item TYPE /scmtms/t_tor_item_tr_k, lt_sts TYPE /scmtms/t_tor_stop_succ_k, lt_id TYPE STANDARD TABLE OF /scmtms/tor_id, lt_selpar TYPE /bobf/t_frw_query_selparam, lt_item_key TYPE /bobf/t_frw_key, lt_key TYPE /bobf/t_frw_key, ls_key TYPE /bobf/s_frw_key, lo_srv_mgr TYPE REF TO /bobf/if_tra_service_manager. FIELD-SYMBOLS : TYPE any. *--------------------------------------------- * 获取TOR业务对象的service manager实例 *--------------------------------------------- lo_srv_mgr = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = /scmtms/if_tor_c=>sc_bo_key ). *--------------------------------------------- * 将alternative key转换为key *--------------------------------------------- APPEND '00000000000610000462' TO lt_id. lo_srv_mgr->convert_altern_key( EXPORTING iv_node_key = /scmtms/if_tor_c=>sc_node-root iv_altkey_key = /scmtms/if_tor_c=>sc_alternative_key-root-tor_id it_key = lt_id IMPORTING et_key = lt_key ). *--------------------------------------------- * 根据key读取node数据 *--------------------------------------------- CALL METHOD lo_srv_mgr->retrieve EXPORTING iv_node_key = /scmtms/if_tor_c=>sc_node-root it_key = lt_key IMPORTING et_data = lt_root. *--------------------------------------------- * 根据key + association读取关联节点数据 *--------------------------------------------- CALL METHOD lo_srv_mgr->retrieve_by_association EXPORTING iv_node_key = /scmtms/if_tor_c=>sc_node-root it_key = lt_key iv_association = /scmtms/if_tor_c=>sc_association-root-stop_succ iv_fill_data = abap_true IMPORTING et_data = lt_sts. *--------------------------------------------- * 根据相应查询条件通过query的方式查询结果 *--------------------------------------------- lt_selpar = VALUE #( ( attribute_name = /scmtms/if_tor_c=>sc_query_attribute-item_tr-qdb_query_by_attributes-platenumber sign = /bobf/if_conf_c=>sc_sign_option_including option = /bobf/if_conf_c=>sc_sign_equal low = '鄂A12345' ) ). lo_srv_mgr->query( EXPORTING iv_query_key = /scmtms/if_tor_c=>sc_query-item_tr-qdb_query_by_attributes " Query * it_filter_key = " Key Table it_selection_parameters = lt_selpar " Query Selection Parameters * is_query_options = " Query Options iv_fill_data = abap_true " Data element for domain BOOLE: TRUE (='X') and FALSE (=' ') * it_requested_attributes = lt_requested_attributes " List of Names (e.g. Fieldnames) IMPORTING * eo_message = " Message Object * es_query_info = " Query Information * et_data = lt_item_res et_key = lt_item_key ).

Retrieve by association(dependent objects)：这类查询对应于独立的业务对象，如附件，不属于任何一个业务节点的属性，是一个公共使用的容器，理解上会相对复杂，会在后续专门介绍。

增删改则都可以通过service manager实例中提供的modify方法来实现

FIELD-SYMBOLS: TYPE /scmtms/s_trq_root_k, TYPE /scmtms/s_trq_q_result. DATA: lo_srv_trq TYPE REF TO /bobf/if_tra_service_manager, lt_mod TYPE /bobf/t_frw_modification, ls_mod TYPE /bobf/s_frw_modification, lv_trq_new_key TYPE /bobf/conf_key, lo_chg TYPE REF TO /bobf/if_tra_change, lo_message TYPE REF TO /bobf/if_frw_message, lo_msg_all TYPE REF TO /bobf/if_frw_message, lo_tra TYPE REF TO /bobf/if_tra_transaction_mgr, lv_rejected TYPE abap_bool, lt_rej_bo_key TYPE /bobf/t_frw_key2, ls_selpar TYPE /bobf/s_frw_query_selparam, lt_trq_qdb TYPE /scmtms/t_trq_q_result. * Get instance of service manager for TRQ lo_srv_trq = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( /scmtms/if_trq_c=>sc_bo_key ). *--- Creating a new TRQ instance ---* ls_mod-node = /scmtms/if_trq_c=>sc_node-root. ls_mod-key = /bobf/cl_frw_factory=>get_new_key( ). *--- set operation ---* ls_mod-change_mode = /bobf/if_frw_c=>sc_modify_create. CREATE DATA ls_mod-data TYPE /scmtms/s_trq_root_k. ASSIGN ls_mod-data->* TO . -trq_type = 'ZENH'. APPEND ls_mod TO lt_mod. lv_trq_new_key = ls_mod-key. lo_srv_trq->modify( EXPORTING it_modification = lt_mod IMPORTING eo_change = lo_chg eo_message = lo_message ).

2.2.4 Transaction Manager

TM中的更改操作需要通过实例化transaction manager来实现保存动作，类似于BAPI_COMMIT操作。

*--------------------------------------------- * 创建transaction manager实例 *--------------------------------------------- lo_tra_manager = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager( ). *--------------------------------------------- * 保存 *--------------------------------------------- lo_tra_manager->save( IMPORTING eo_message = lo_message " Interface of Message Object ).

2.3 FPM

FPM是基于web dynpro开发的一套更加标准化，对于开发者更加友好便捷的UI开发框架。同时FPM对于开发也是很强大一项技能，篇幅有限不在此展开，会在后续补充FPM开发的相关详细知识

2.3.1 框架介绍

常用的FPM框架主要分为三类：

l OVP（Overview Page Floorplan）：使用的时候引用FPM_OVP_COMPONENT，最灵活的一种模式，采用stack的概念来安排界面，这是其他component没有的

l OIF（Object Instance Floorplan）：使用的时候引用FPM_OIF_COMPONENT，进去之后默认只有一个tab UIBB为主界面，所有其他的UIBB要加到这个tab UIBB中去，缺点是只有当前显示的tab下的UIBB能获取到抛出的事件，没有显示的UIBB的feeder class无法获取到抛出的事件

l GAF（Guided Activity Floorplan）：使用的时候引用FPM_GAF_COMPONENT，step by step的模式，常用于一步一步指导过程的向导式界面，能清晰的看到执行的顺序以及将要执行的步骤，可以参考在NWBC上设置POWL时的界面，就是基于GAF开发的，如下图：

图表 6

在TM中主要使用的是OVP，同时也是最灵活的一种。

2.3.2 技术框架

图表 7

l Interfaces：SAP标准接口，提供相关方法，对应到相关标准的控件

l FeederClass:实现SAP的Interfaces的方法，通过FeederClass控制UI控件

l UIBB:WEB控件

l App Controller：控制器接口，控件的总入口和出口，实现事件统一控制

2.3.3 相关接口

SAP通过内置了大量的标准接口来实现代码的标准化，我们只需要实现对应的接口作为FeederClass，然后再将FeederClass绑定给UI即可。

接口

说明

IF_FPM_GUIBB_FORM

FORM表单控件

IF_FPM_GUIBB_FORM_EXT

FORM表单控件扩展

IF_FPM_GUIBB_LIST

TABLE LIST控件

IF_FPM_GUIBB_LIST_EXT

TABLE LIST控件扩展

IF_FPM_GUIBB_SEARCH

搜索控件(配合LIST一起使用搜索加结果)

IF_FPM_GUIBB_TREE

树形节点控件

2.4 Wire Model

线模型，用于通过纯配置来实现FPM应用之间的运行时相关性，比如能根据源UIBB的修改输出来决定目标UIBB的数据内容，例如我们在NWBC界面修改FWO的item某一个list信息，可能会更改FWO item相关的另一个list信息。

例如，我们在NWBC界面做增强，需要为展示FO的界面增加一个UIBB，那么我们肯定会需要定义这个新的UIBB的数据来源，而通过定义Wire Model就能实现，将新的UIBB与已存在的用于显示业务对象实例的UIBB关联起来，如下图：

图表 8

图表 9

重要属性名及属性值详解：

Component:目标UIBB的组件类型，此处为FPM提供的通用List UIBB

Configuration ID:目标UIBB的配置ID

Instance ID:默认为1，暂未了解其他用法

Source Component:源UIBB组件类型

Source Config Name:目标UIBB的配置ID

Source Node Association:源UIBB对应的业务对象节点与目标UIBB对应的业务对象节点之间的关联

Connector Class:提供标准的方法将FPM，FBI及BOPF与Wire Model连接

2.5 FBI

FBI即FPM与BOPF集成，FPM,FBI及BO Layer之间的技术关联图如下：

图表 10

FBI相关概念如下：

2.5.1 FBI View(design time)

在NWBC界面查看对应的FBI View名称，如下图所示：

图表 11

图表 12

包含界面对应的业务对象，业务对象节点，节点UI结构，Mapper Class和Exit Class。

2.5.2 FBI View Instance(runtime)

FBI View的实例包含了显示的实例的key值（来源于与UIBB连接的Wire Model），FBI View实例能将修改，执行动作，以及变更通知发送到FBI Controller中，它会对FBI特定的SYNCUP事件作出反应，根据变更通知来决定哪些key值需要刷新，另外，它可以用已修改的Key值在node buffer或者BO层获取数据，并可以在需要的地方调用Mapper Classes和Exit Classes

2.5.3 FBI Controller(runtime)

用于集中BO层的响应，不包含任何应用程序逻辑，知识提供业务流程的技术框架，为UI上的更改提供一个修改的缓冲区，然后再将缓冲区的数据再转发到BO层，同时它还能手机来自BO层的更改通知，然后再UI上触发更新，缓冲区的存在可以保存来自BO层的节点信息，节点属性等，有助于避免冗余的BOPF服务调用。

2.5.4 Conversion Classes

即Mapper Class，用于将数据在BO 层和UI层进行转换，数据从BO层到UI或者数据由UI返回到BO层，转换的过程在获取数据后，发送更改到缓存之前。

所有的Conversion Classes的实现都继承于TM的超类/SCMTMS/CL_UI_CONVERSION，对其继承后都需要重定义方法BUILD_MAP_TABLE，超类已经包含一些通用的转换规则，比如时间戳到年月日的转换，时间戳到年月日字符串的转换，key与Alternative Key之间的转换

2.5.5 Exit Classes

FBI的大部分逻辑处理都在Exit Classes中实现，因此也是TM增强的一个核心，所有的类实现继承于超类/SCMTMS/CL_UI_VIEWEXIT_CMN，一个Exit Class需要实现下列接口：

l 核心接口：/BOFU/IF_FBI_VIEW_EXIT_INTF，此接口不含任何方法，用于让FBI对此类实例化对象

l 定义接口：/BOFU/IF_FBI_VIEW_EXITINTF_DEF，此接口主要用于更改FPM中的get_definition方法（仅在初始化时运行一次），有以下方法：

ADAPT_FIELDS用于修改字段目录；

ADAPT_ACTIONS用于修改操作目录；

ADAPT_DND_DEFINITION用于修改下拉框定义

l 定义接口：/BOFU/IF_FBI_VIEW_EXITINTF_RUN，此接口主要用于影响用户交互的进程即FPM中的GET_DATA,PROCESS_EVENT,FLUSH等方法（在每次交互时触发），有以下方法：

ADAPT_CHANGE_LOG用于将UI的修改在转换成BO修改记录之前进行更改；ADAPT_EVENT用于处理事件；

ADAPT_MESSAGES用于修改来自modify或者do_action的消息；

ADAPT_DATA用于在数据传递到FPM之前，修改数据，需要注意的是，这里的数据都是以参考字段的形式，因此访问UI结构需要通过’ASSIGN COMPONENT’来实现；

ADAPT_FIELD_PROPERTIES用于修改字段属性；

ADAPT_ACTION_PROPERTIES用于修改action的是否可用属性；

ADAPT_SELECTION用于修改已选择行（在List或Tree UIBB中）

3 TM报表POWL

会在后续更新

4 TM表单打印

会在后续更新

5 TM增强开发 5.1 BOPF增强

事务代码：BOB

增强界面如下图：

图表 13

如果要对列表里的标准业务对象进行增强，首先要为这个业务对象创建增强对象，此增强对象并不是替代或拷贝标准的业务对象，只是作为一个存放增强的容器，而标准的业务对象会作为super BO 或者base BO

增强对象如下图：

图表 14

上面不是灰色的节点允许增强，下面显示的是所有节点的实体操作，如果需要看某个节点对应的操作，双击该节点即可

图表 15

这两个自动生成的组合结构除了包含节点对应的字段外，还会包含db key,parent key,root key

数据库表则是给出了这个节点数据存储的表名

5.1.1 创建增强对象

选择需要增强的节点，右击选择创建增强

图表 16

图表 17

图表 18

每个增强对象都有它对应的常量接口（系统在创建增强对象时自动生成的）

图表 19

对此增强对象下的属性进行更改时，需要点击重新生成按钮，更新常量接口

5.1.2 创建字段扩展

增强节点元素并没有添加到标准常量接口中而是添加到对应的增强对象的常量接口中

图表 20

通过永久包含或过渡包含接口进行扩展（过渡包含的用于那些可能只用一段时间的增强字段）

图表 21

点击附加结构添加扩展字段，里面的字段名尽量按照ZENH_*的形式进行命名

5.1.3 创建子节点

图表 22

选择增强对象的某个节点，右键选择创建子节点，子节点的命名规范ZENH_ROOT_SUBNODE

图表 23

图表 24

双击进入，创建此结构（这两个结构用于此子节点的字段扩展）

图表 25

图表 26

选择结构的增强类别

图表 27

这两个结构创建后，还需要创建两个结构，即此子节点本身应有哪些字段的结构，点击next

图表 28

这两个结构也分别创建，同上（也需要选择增强类型），输入Node的字段，并include上之前创建的两个结构

图表 29

需要注意的是，永久结构里面包含的应该是永久扩展结构，过渡结构里面包含的应该是过渡扩展结构

图表 30

接着点击下一步，会自动创建这些结构和表，如果此步完成后，点击下一步完成，报错“node couldn’t be created”，那么需要检查一下对应的结构，组合表类型，以及数据库表是否创建成功，因为系统自动创建这些数据结构时，系统会自动加上一些字段，如MANDT,ROOT_KEY,DB_KEY,PARENT_KEY等可能会与自己创建的结构中的字段名重复导致创建失败，但没有详细的错误消息，因此很难发现

图表 31

5.1.4 创建活动

图表 32

选择操作基数：多个节点实例表示这个操作可以操作在一个或多个节点实例上，单个节点实例表示这个操作只能操作在一个节点实例上，而静态操作则是无法操作在节点实例上

图表 33

可点击建议名称，双击结构进入创建界面（SE11），此结构用于action的额外要求传入传输

图表 34

双击进入实施类

图表 35

双击进入EXECUTE方法进行编辑

图表 36

5.2 FPM增强

图表 37

如果需要对FPM进行增强，需要通过事务代码SICF检查FPM可增强服务是否已激活

图表 38

可以通过一个通用的方式去访问：

http://[server]:[port]/sap/bc/webdynpro/sap/wd_analyze_config_comp

如下图，选择查询方式

图表 39

5.2.1 字段增强

基本思路：先找到FPM对应的BO node，然后在BOBF中找到此BO node对应的extension include，对此结构附加字段，最后再在FPM的配置界面，选择对应的字段进行添加

找到需要增强的页面，在某个字段上，右键选择technical help

图表 40

得到组件配置名：

图表 41

点击link导航至此配置界面

图表 42

得到FBI view

图表 43

新建窗口

图表 44

输入FBI view，点击display

图表 45

得到此界面关联的BO node

图表 46

然后通过事务代码BOBF，获取到此节点对应的增强结构

图表 47

或者直接根据上述提供的链接查询组件配置ID

如果未生效，则可以将extension include直接append到UI对应的结构上

图表 48

5.2.2 操作增强

基本思路：同上，先找到需要增加toolbar button的界面对应的configuration id，获取其对应的BO node，在BOBF开发工作台中找到此节点对应的action，新增action后，会自动生成绑定的类，然后实施类中的execute方法，最后在FPM前台，添加toolbar，选择新建的action进行绑定

图表 49

在类中抛出消息的示例代码：

图表 50

5.2.3 页签增强（数据来源于增强的子节点）

此增强适用于，需要与SAP中标准的业务对象有着业务上的关联关系且需要展示的场景，而D页签增强（数据来源于外部数据）适用于与标准业务对象基本无关仅需要展示的场景，注意不同增强的使用场景

基本思路：找到需要增强页签的界面，找到对应的BO node，在BO node上增加子节点（需要定义1.永久结构，2.组合结构即包含db_key,root_key,parent_key和永久结构的结构，3.组合表结构，4.数据库表）以及在子节点上新增action（用于页签里的按钮事件），然后需要创建一个新的UIBB（也就需要新的component configuration和feeder class，并编辑feeder class parameter设置业务对象和节点为新增的子节点），绘制页面（设置显示字段，添加按钮等），最后将此UIBB挂载到标准界面上

增强通用链接：

https://[server]:[port]/sap/bc/webdynpro/sap/configure_component

按照之前的步骤创建子节点后，先创建一个UIBB

图表 51

输入组件名，此处展示为list形式，如为其他形式，需要更改命FPM_XXX_UIBB_ATS

同时，configuration id的命名建议遵循以下规范:ZENH_WDCC_XXX_XXX_UIBB分别为描述和展示形式

点击创建，选择包与请求，输入对应类型的feeder class: /BOFU/CL_FBI_GUIBB_LIST_ATS

图表 52

编辑feeder class parameter，在此处填入增强的子节点以及其根节点（数据来源）

图表 53

编辑UIBB，添加field,action等，并修改其属性，保存UIBB

图表 54

下一步为找到需要添加此UIBB的主页面，然后找到其configuration id，方法如下：右键点击主页面，选择技术帮助，然后start component中的component configuration即对应我们需要增强的主页面

图表 55

双击进入，或者复制进行搜索，然后显示，由于主页面有很多个page，我们需要选择main page，然后编辑

图表 56

选择overview page schema点击添加list component，并输入刚才创建的UIBB的configuration id

图表 57

编辑list component的属性，注意此处的title即为展示的页签的标题

图表 58

最后添加wire schema，用于定义UIBB从哪里去取数来展示，它能将已抓取当前展示的业务对象信息的此界面的UI与我们新建的UIBB进行关联，从而获取数据

图表 59

编辑wire list属性

图表 60

创建tab成功，查看效果

5.2.4 页签增强（数据来源于外部非业务对象节点）

基本思路：先创建用于展示数据的数据源表，然后创建FBI view（包含标准的BO node/UI structure/mapper class/exit class，通过复制标准的BO node对应的FBI view获得，并在UI structure中增加自己需要的字段），创建list UIBB（包含feeder class即标准的list class，刚才创建的FBI view信息），配置list UIBB的字段，然后在主页面中添加UIBB，并通过增加wire list将UIBB与UI绑定，重写mapping class和exit class中的相关方法，通过代码将数据来源指向自建表